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Description 

FIELD OF THE INVENTION: 

5 [0001 ] Th is invention re lates to a method for converting a string of formatted computer readable characters to a new 
string having a new format. 

DESCRIPTION OF RELATED ART: 

10 [0002] The move in the microcomputer industry from the Microsoft© Windows™ version 3.X graphic environment, 
which runs under the 8/16-bit MS-DOS operating system, to the 32-bit Microsoft Windows 95 operating system has 
created a number of problems. Although Windows 95 has been designed so that It wilt run most software written for 
Windows ver. 3.X, programs which are written to take full advantage of the expanded capabilities of Windows 95 are 
often incompatible with Windows ver 3.X. 

IS [0003] One of the incompatibilities between the old and new versions of Windows relates to path names. A path 
name is a unique identifier assigned to each file in a distributed data processing system. A path name, as it appears 
to the end user, has a similar format under both Windows ver. 3.X and Windows 95. The path name for any file always 
begins with a host identifier and ends with a file name. For example, "C:\WINDOWS\SYS\FILE.EXE" and 
"\\HOST\J\WINDOWS\SYS\FILE.EXE" are path names representative of those used with Windows ver 3.1. The first 

20 example does not follow the l/hiform Afeming Convention (UNC)\ the second example does. Directories, subdirectories 
and file names are limited to eight characters plus a three character extension. Generally, however, it is customary to 
use three character extensions for only file names. The UNC path name contains a host designator "host" and a shared 
designator 'J". It will be noted that the UNC path name begins with double backslash characters, and that no colon 
character is used in the UNC name. 

2S [0004] Windows ver. 3.X uses /American Standard Cbde for Aifonmation /nterchange (ASCI Hot short). As each ASCII 
character is represented by a single byte (eight bits], 256 characters are the maximum that may be represented by 
the ASCII character set. Given the substantial decreases in the cost of both semiconductor and rotating magnetic 
storage memory, It Is not surprising that ASCII code is being supplanted by a new, less-efficient but more capable code 
based on two-byte characters. The new code, called Unicode, can distinguish between 65,536 characters, a quantity 

30 sufficient to encompass all foreign alphabets and the Chinese/Kanji characters. 

[0005] A path name under Windows ver. 3.X is stored as it appears on a computer screen. That is to say that, In the 
case of a UNC path name, it is stored as a string of ASCII characters which begins with the double backslash ("W") 
and ends with the file name. The elements of the path name (e.g. host, shared, directory, subdirectories, and file name) 
are separated from one another by a single backslash (V). The string is terminated by a null byte (i.e. one which is 

35 set to OOHEX). A non-UNC path name is stored beginning with a letter for the drive designator and ends with the file 
name. 

[0006] A path name under Windows 95, on the other hand, is stored as a specially formatted Unicode string known 
as parsed path name structure. Such a structure omits both the host name and the shared name in the case of a UNC 
name, or the drive designator in the case of a non-UNC path name, and has the following format: The first Unicode 

40 value, or byte pair, specifies the total length of the parsed path name structure in bytes; the second Unicode value 
indicates the length, in bytes, of the prefix (in this case, the prefix begins with the first Unicode value of the string, and 
includes the directory and all subdirectories up to. but not including, the file name); the third byte pair indicates the 
length, in bytes, of the first path element in the prefix after the shared drive specifier or initial drive specifier (in the case 
of a non-UNC name), including the backslash character with which it begins; the third byte pair Is followed by an array 

45 of Unicode values corresponding to the characters In the name of the first path element; the first path element name 
array is followed by a subsequent byte pair which indicates the length, in bytes, of a second path element (if any); other 
subsequent byte length indicators and Unicode arrays may follow, depending on the number of subdirectories which 
precede the file name; the final path element is the file name, and it, like other path element, is preceded by a byte 
length Indicator. 

so [0007] The need for the present invention arose during the development by Sun Microsystems, Inc. of a caching 
program module which would operate under both Windows 95 and Windows ver. 3. 1 1n a networked environment which 
may include modem connections. The module was initially written to operate with Windows 95. As such, it expected 
inputs, such as parsed path name structures, which are peculiar to Windows 95. If the program were to be run in a 
Windows ver. 3.X environment, the zero-terminated path names characteristic of Windows ver. 3.X would require con- 

ss version to the parsed path name structures. 

[0008] EP-A-0,568,488 describes a method for accessing the same computer file using different file name formats, 
of different operating systems. A directory specific request is received from a user This directory specific request may 
contain no prefix or suffix, or this directory specific request may contain one of number of operating system specific 
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prefixes/suffixes. Any prefix or suffix that is contained in the directory specific request Is Identified, for example DOS. 
MACINTOSH, OTHER. When no prefix/suffix is used in the request, the specified directory is searched, and it is de- 
termined if the requested item is found in the specified directory. When use of a prefix/suffix is found in the directory 
specific request, the found prefix/suffix is stripped, and a lookup strategy is used that Is related to the found prefix/ 
5 suffix. It is then determined If the requested item was found in the specified directory using the prefix/suffix related 
lookup strategy of one of the previous steps. Thus, four search strategies are provided; i.e., (1 ) when no prefix/suffix 
is used, (2) when the DOS prefix/suffix Is used, (3) when the MACINTOSH prefix/suffix is used, and (4) when the 
OTHER prefix/suffix is used. 

[0009] IBM Technical Disclosure Bulletin, Vol.32, no. 10a, March 1990, pp. 456 - 462 "File Mapping in a heteroge- 
10 neous distributed environment" discloses a method for converting path names between different formats. A method is 
described that handles the mapping of FILE IDs from one operating system to a second operating system. In order to 
accomplish this, a PROFILE must be created before mapping use. This PROFILE contains a set of RULES that de- 
termine how a given FILE ID is mapped from a first operating system to a second operating system pair, and the details 
of the RULES must differ depending upon the specific operating systems involved in the operating system pair since 
IS a logical connection is established between two different operating systems for each different RULE. 

[0010] M. Davis et al in "Unicode"; 1 990 IEEE International Conference on Systems, Man and Cybernetics, Confer- 
ence Proceedings, 4 - 7 November 1 990, Los Angeles, CA, USA, pages 499 - 504, discusses the fundamental design 
principles for encoding characters in computers using Unicode. 

20 SUMMARY OF THE INVENTION 

[0011] The present Invention provides a method for converting an ASCII path name to a parsed path name structure 
in accordance with the appended claims. 

[0012] In accordance with this inventbn, the above problem has been solved by the development of an efficient 
2S method implemented in conjunction with a computing system for converting a zero4emriinated ASCII path name to a 
parsed path name structure. 

[001 3] The above computer implemented steps in another Implementation of the Invention are provided as an article 
of manufacture, i.e., a computer storage medium containing a computer program of instructions for performing the 
above described steps. 

30 [0014] The great advantage and utility of the present Invention is the efficient conversion of ASCII path names to 
parsed path name structures. The invention permits program modules designed to run under operating systems that 
provide parsed path name structure Inputs to run under other operating systems which provide only ASCII path name 
inputs. 

[0015] The foregoing and other features, utilities and advantages of the invention will be apparent from the following 
3S more particular description of a preferred embodiment of the invention as illustrated in the accompanying object code 
listing and in the drawings. 

Brief Description of Drawings 

40 [0016] 

Fig. 1 illustrates a representational computing system and operating environment for performing the computer 
implemented steps of the method in accordance with the invention; and 

Fig. 2 is a flow chart depicting buffer contents at various stages during the conversion of a non-UNC ASCII path 
4S name to a parsed path name structure; and 

Fig. 3 is a flow chart depicting buffer contents at various stages during the conversbn of a UNC ASCII path name 
to a parsed path name structure. 

Detailed Description of Preferred Embodiments 

so 

[001 7] The embodiments of the invention described herein may be implemented as logical operations in a distributed 
processing system having client and server computing systems. The logical operations of the present invention are 
implemented (1 ) as a sequence of computer implemented steps running on the computing system and (2) as intercon- 
nected machine modules within the computing system. The implementation is a matter of choice that is dependent on 
ss the performance requirements of the computing system implementing the invention. Accordingly, the logical operations 
making up the embodiments of the invention described herein are referred to variously as operations, steps or modules. 
[0018] The operating environment in which the present invention Is used encompasses the general distributed com- 
puting system, wherein general purpose computers, workstations, or personal computers are connected via commu- 



3 



EP 0 800 142 B1 



nication links of various types, in a client-server arrangement, wherein programs and data, many in the form of objects, 
are made available by various members of the system. Some of the elements of a general purpose workstation com- 
puter are shown in Figure 1, wherein a processor 1 is shown, the processor having an input/output (I/O) section, a 
central processing unit (CPU) 3 and a memory section 4. The I/O section 2 is connected to a keyboard 5, a display 

5 unit 6, a disk storage unit 9 and a CD-ROM drive unit 7. The CD-ROM unit 7 can read a CD-ROM medium 8 which 
typically contains programs 10 and data. The computer program products containing mechanisms to effectuate the 
apparatus and methods of the present Invention may reside in the memory section 4, or on a disk storage unit 9, or 
on the CD-ROM 8 of such a system. Examples of such systems include SPARC® systems offered by Sun Microsys- 
tems, Inc., personal computers offered by IBM Corporation and by other manufacturers of IBM-compatible personal 

10 computers, and systems running the UNIX® operating system. 

[001 9] As a starting point for describing the invention, an object code listing of a computer program which Implements 
the method Is provided. The program, written in C code, Is considered to be a preferred implementation of the method. 
Although other high-level languages might be used to Implement the method, C Is considered to be particularly well- 
suited, as large portions of Windows ver. 3.X and Windows 95 are believed to have been written In C. 

IS 
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conversion Routine in c 

typedef PareedPath ♦path^t; 
typedef unsigned short *8tring_t; 

struct PathElement { 

unsigned short pe^length; 

unsigned short pe"~unichar8[l]; 
}f /*Path Element */ 

struct ParsedPath { 

unsigned short pp^totalLength; 

unsigned short pp^pref ixLength; 

struct PathElement pp_element8(l] 
}; /* ParsedPath */ " 

//From sunwifs.c 

//NameJam * converts ASCII pathname into unicode/path struct 
INT 

NameJam(PPCHAR pPathName, 
PCRS per 8, 
path_t *pppath, 
string t *puFName, 
string"t *pupath) 



INT Len; 

2s USHORT chCount; 

string t UnlBuf; 

string^t UniPath; 

string_t pUniEnd; 

8tring_t pUni; 

string t uFNamef 
30 PUCHAR'~pStr; 



PUCHAR PathName - *pPathName; 
UNIT DrlveNo; 

*pPathMaffle - (PCHAR)LowBuf ; 
PathName • LowBusi 

If (pupath) { 

pUniEnd - OnlBus = *pupath; 



//convert the ASCII pathname to unlcode 
for (pStr ■ PathName; *pStr; ) 
40 •pUnlEnd^-t* » *pStr++; 

*pUniEnd— » '\0'; 
// Fing last '\' for uFName 

for (uFName » pOnlEnd; *uFName l« '\\'? uFName— ) 



// And point to the next character 
uFName^«^; 

*puFName » uFName; 

> 

// if UNC, only convert after the share name 



55 
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it (PathNaine(0] =»- '\\' &fi PathName(lJ == '\\') { //UNC 
// first f advance to beginning of share name 
PathName « strchr(&PathNaffle[2 ] , '\\'); 

// then, advance to beginning of pathname after share name 
s if (PathName) 

PathName » strchr(PathName+l, '\\'); 
if (PathName NULL) { 

return (-1); 

} 

// move back 2 characters to hold ParsedPath structure 
10 PathName -» 2; 

Len » strlen( PathName) ; 

pUniEnd = UniPath = (string_t) ♦pppath; 

// Convert the ASCII pathname to unicode«** 
for (pStr = PathName; ♦pStr; ) 

*pUniEnd*+ = *pStr++; 
•pUniEnd— « '\0'; 

// Find last '\' for pp prefixLength 

for (pUni « pUniEnd; *pUni 1= '\\'; pUni~) 

UniPath(l] « (pUni - UniPath) *2; //pp prefixLength 

UniPathjO) = 2 * Len; //pp_totalLength (w7o trailing null) 

/** Now back upf counting characters, replacing the '\' with the 
2g * count (i.e., setting pe_length) •/ 

for (chCount - 0; pUniEnd >• &UniPath(2]l pUniEnd — ) 
if (*pUniEnd •« 'W { 

•pUniEnd — « ♦+chCount * 2; //pe_length 
chCount -0; " 

) 

go chCount ++; 

> 

[0020] Although it is assumed that those having ordinary skill in the art of computer programming will fully understand 
the logic and function of the heretofore listed computer program, a general description of the program is provided to 
35 assist the reader 

[0021] The program begins with several type definition statements and with the definition of a parsed path structure. 
The parsed path structure is defined as being comprised of multiple elements, each of which is an array of Unicode 
characters. 

[0022] The "NameJam' program converts the ASCII pathname first to an unparsed Unicode character string and 
40 later converts the unparsed string to a parsed path name structure. The NameJam program begins with the definition 
of various pointers and the allocation of various stack variables. The parsed path name structure will be assembled in 
a buffer designated pppath. The ASCII path name is loaded in a buffer designated PathName. 
[0023] Prior to converting the ASCII path name to the unparsed Unicode character string, the NameJam program 
must first determine whether or not the ASCII path name follows the Uniform Naming Convention (UNC). An ASCII 
45 path name which does not follow the UNC begins with a drive specifier character followed, respectively, by a colon 
character, a single backslash character, a prefix character string, another single backslash character, and a file name 
character string. On the other hand, an ASCII path name which follows the UNC begins with a pair of adjacent backslash 
characters followed, respectively, by a host name character string, a single backslash character, a shared name char- 
acter string (which may be only a single character), a single backslash character, a prefix character string (which may 
so include several elements separated by backslash characters), another single backslash character, and a file name 
character string. It should be noted that each backslash character preceding a path element is considered to be a part 
of that path element. Examples of both a non-UNC ASCII path name and a UNC ASCII path name are, respectively: 
C:\WINDOWS\SYS\FILE.EXE (non-UNC) 
and 

55 \\DENVER\J\WINDOWS\SYS\FILE.EXE (UNC) 

[0024] If the ASCII path name follows the UNC, only the portion of the path name after the shared name and beginning 
with a backslash character is converted to a Unicode character string and two dummy characters are placed at the 
beginning of the string. Alternatively the conversion is begun two characters to the left of the fourth backslash character 
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(i.e. , at the backslash character immediately to the left of the character "J" in the UNO example above) and no dummy 
characters are placed at the beginning of the string. In either case, the result is the same. 

[0025] It the ASCI I path name does not follow the UNC, it is assumed that the path name begins with a drive specifier, 
followed by a colon character and a backslash character, respectively. The entire non-UNC path name is converted to 

5 a Unicode character string. 

[0026] A character by character conversion of the ASCI I path name to Unicode is effected, and the buffer designated 
pppath Is sequentially filled with the Unicode characters, thus creating an unparsed Unicode character string. 
[0027] After all required character codes of the ASCII path name are converted to Unicode values, and the Unicode 
values have been written to the pppath buffer, a null Unicode character is appended to the end of the unparsed string. 

10 [0028] A first pointer is set on the first Unicode character of the unparsed string within buffer pppath. For the non- 
UNC example listed above, the first character is "C"; for the UNC example listed above, the first character is either the 
first extra character or the backslash (V) character Immediately preceding the character "J". 
[0029] The contents of buffer pppath are then scanned and counted in a direction from beginning to end, beginning 
with the first character in the unparsed string, and stopping on the appended null character Let us call the total number 

IS of characters counted T+1 , as this quantity includes the null character 

[0030] The second pointer is then shifted one character toward the first character so that it points to the last character 
in the string that is immediately adjacent the appended null character. The count is adjusted during the shift so that 
the total number of characters in the unparsed string is determined to be the quantity T T is doubled to reflect the fact 
that each Unicode character value contains two bytes. Thus, for both the UNC and non-UNC examples above, 2T = 

20 46 bytes. The first character position in the pppath buffer (i.e., the "C" for the non-UNC case and the first extra character, 
or the T immediately to the left of the character "J" for the UNC case) replaced with the Unicode value for the number 46. 
[0031] A scanning operation is then performed with a third pointer, beginning with the Unicode character pointed at 
by the second pointer (i.e., the character before the appended null), and in a direction toward the first pointer, stopping 
on the first backslash character encountered, and counting the number of characters, F, beginning with the character 

2S pointed at by the second pointer and ending with the first backslash character on which the third pointer stopped. For 
both the non-UNC and the UNC cases, the file name length F in Unicode characters is equal 9. Thus the file name has 
a byte length of 2F, or 18 bytes. The backslash character to which the third pointer still points is replaced with the 
Unicode value for the number 18. 

[0032] A number P is detemnined, whteh represents the length, In bytes, of the prefix. P is calculated by subtracting 
30 2F from 2T, or F from T and doubling the result. For both the UNC and non-UNC cases shown above, P = 28 bytes. 
The second Unicode character in the buffer (e.g., the colon for the non-UNC case and the second extra character or 
the character 'J" for the UNC case are each replaced with the unk:ode value for the number 28. 
[0033] The scanning and counting process is repeated, each time moving in a direction toward the first pointer to 
the next backslash character, counting the number of characters in that string element, multiplying the number of 
3S characters by 2 to obtain the string element byte length, and replacing the backslash character immediately preceding 
each element with a Unicode character which specifies the length of the element in bytes. For example, the backslash 
character immediately preceding the element "SYS" for both UNC and non-UNC strings is replaced with the Unicode 
value for the number 8. which is the byte length of that element including the initial backslash, and the backslash 
character immediately preceding the element "WINDOWS' for both UNC and non-UNC strings is replaced with the 
40 Unicode value for the n umber 1 6, 

[0034] At this stage of the process, the unparsed Unicode string in buffer pppath has been completely converted to 
a parsed path name structure. 

[0035] The flow chart of Figu re 2 depicts the contents of the PathName buffer and the pppath buffer at various stages 
during the conversion of a non-UNC ASCII path name to a parsed path name structure. The non-UNC ASCII path 
45 name is first loaded into the PathName buffer 21 . Although the contents of PathName buffer 21 are depicted by char- 
acters, each byte-wide memory location within the PathName buffer 21 actually contains the binary ASCII code which 
represents the character. For example, the character "C" would be represented by the binary code "01100111" which 
is expressed in hexadecimal notation as "67". 

[0036] Still referring to Figure 2, for a non-UNC name, the entire path name Is converted character-by-character to 

so two-byte-wlde Unicode and sequentially loaded into the pppath buffer 22A as an un-parsed Unicode character string. 
A null character, represented by sixteen zeros or "00 00" in hexideclmal code, is appended to the unparsed Unicode 
character string. 

[0037] Still referring to Figure 2, the unparsed character string is then converted to a parsed path name structure, 
which is depicted by pppath buffer 22B (the same buffer as 22A, but with different contents) by converting the code 
ss for the first character (the letter "C") to a Unicode numerical value which represents the length of the Unicode character 
string, minus the null character, In bytes. Thus, the Unicode value for "C" is replaced by the Unicode value for 48 (the 
string length in bytes), which is represented by "00 2E" in hexidecimal notation. The Unicode value for the colon char- 
acter, "00 3A" is replaced by the Unicode value for 28 (the length of the prefix in bytes), which is represented by "00 
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1C" in hexidecimal notation. The prefix, of course, comprises every character ot the string from "C to the third "S". 
The Unicode value for each backslash character (V) is replaced by the Unicode value which corresponds to the length, 
in bytes, of the immediately following path element. That is to say, the first "00 2F" is replaced by "00 10", which 
represents the byte length of the Unicode element "\WINDOWS": the second "00 2F' is replaced by "00 08", which 
5 represents the byte length of the Unicode element "\SYS"; and the third "00 2F" is replaced by "00 1 2", which represents 
the byte length of the Unicode element "\FILE.EXE". 

[0038] Conversion of a UNO ASCII path name to a parsed path name structure proceeds by a slightly different 
process than that for non-U NC ASCII path names. The flow chart of Figure 3 depicts the contents of the PathName 
buffer and the pppath buffer at various stages during the conversion of a UNC ASCII path name to a parsed path name 

10 structure. The entire UNC ASCII path name is first loaded into the PathName buffer 31 . It will be remembered that a 
UNC ASCII path name begins with two adjacent backslash characters. Thus, when the ASCII path name is scanned, 
the program identifies such a path name as a UNC path name. Those which begin with a single backslash are assumed 
to begin with a drive identifier, which is followed by a colon, the prefix and the file name. As in Figure 2, although the 
contents of PathName buffer 21 are depicted by characters, each byte-wide memory location within the PathName 

IS buffer 21 actually contains the binary ASCII code which represents the character 

[0039] Still referring to Figure 3, for a UNC name, the portion of the path name to the left of the second character to 
the left of the prefix is discarded during the conversion of the ASCII path name character codes to Unicode. The pppath 
buffer 32A contains the balance of the path name string, as converted to Unicode. Conversion to the final parsed path 
name structure is effected in a manner identical to that employed for a non-UNC ASCII path name. The result is shown 

20 in pppath buffer 32B (the same buffer as buffer 32A, but with different contents). 

[0040] While the invention has been particularly shown and described with reference to a preferred embodiment 
thereof, it will be understood by those skilled in the art that vartous other changes in the form and details may be made 
therein without departing from the spirit and scope of the invention. For example, various techniques and sequences 
may be employed to count characters, determine element lengths, and substitute element length numbers for backslash 

2S characters, blank space characters and other characters at the beginning of the prefix. 



Claims 

30 1 . A method for automatically converting an ASCI I path name to a parsed path name structure (22B, 32B), said ASCI I 
path name having a file name element and a prefix element, said prefix element having at least one subelement, 
said method comprising the computer implemented steps of: 

(a) defining a parsed path name structure; 
3S (b) allocating buffers for stack variables; 

(c) defining a set of scanning and counting functions and a set of arithmetic and character replacement func- 
tk)ns and creating a plurality of pointers for use with said scanning and counting functions and said arithmetic 
and character replacement functions; 

(d) determining whether or not Uniform Naming Convention is used for the ASCII path name; 

40 (e) converting each character of the ASCI I path name or a subset thereof to a corresponding Unicode character, 

and sequentially writing each Unicode character to a buffer to form an unparsed Unicode string (22A, 32A); 
(f) employing the scanning and counting functions, in combination with the arithmetic and character replace- 
ment functions to convert a first pair of buffer locations to numerical values which are indicative of the total 
Unicode string length and the prefix element length, respectively, and to replace each Unicode character cor- 

4S responding to a backslash character within said Unicode string with a specific numerical value, Indicative of a 

length, in bytes, associated with the path name element which began with the replaced backslash character 

2. The method of Claim 1, in which the step of defining a parsed path name structure comprises defining a string of 
Unicode characters, sakl string having a first Unicode character which is assigned a first numerical value specifying 

so a length, in bytes, of saki string, said string further comprising a first array of Unicode characters which represent 
said prefix element, said first array being followed by a second array of Unicode characters which represent the 
file name element, said first Unicode character being followed by a second Unicode character which is assigned a 
second numerical value specifying a length, in bytes, of said prefix element plus four bytes which account for said 
first and second Unicode characters, said second Unicode character being foltowed by a third Unicode character 

ss which is assigned a third numerical value specifying a length, In bytes of a first subelement of said prefix element, 
any further subelement of said prefix element and said file name element each being preceded by a corresponding 
Unicode character which Is assigned a numerical value specifying Its length In bytes. 
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3. The method of Claim 1 , in which the step of determining whether or not the ASCII path name follows a Uniform 
Naming Convention (UNC) comprises identifying: 

an ASCII path name which does not follow said UNC beginning with a drive specifier character followed, 
5 respectively, by a colon character, a prefix beginning with a first single backslash character, and a file name 

beginning with a second single backslash character; 

an ASCII path name which follows said UNC beginning with a pair of adjacent backslash characters folbwed, 

respectively, by a host name, a shared name which begins with a first single backslash character, a prefix 
which begins with a second single backslash character, and a file name which begins with a third single back- 
10 slash character. , 

4. The method of Claim 3, 

wherein, for ASCII path names which do not follow said UNC, each character of the ASCII path name is 
IS converted to the corresponding Unicode character and written to the buffer to form the unparsed Unicode string 

(22A); and 

wherein, for ASCII path names which follow said UNC, two extra Unicode characters are written at the beginning 
of the buffer, and each character of a subset of the ASCII pathname, said subset comprising the prefix element 
and the file name element, is converted to the corresponding Unicode character and placed immediately ad- 
20 jacent said two extra characters, and wherein said two extra characters and the characters corresponding to 

said prefix element and said file name element comprise the unparsed Unicode string (32A). 

5. The method of Claim 4, wherein conversion of the unparsed Unicode string (22A, 32A) to a parsed path name 
structure (22B, 32B) comprises the steps of: 

2S 

(a) determining a number T, which represents a total number of Unicode characters in said string beginning 
with a first character of said string and ending with a null Unicode character which represents a last character 
of the Unicode string; 

(b) assigning to said first Unicode character of said unparsed Unicode string a numerical value equivalent to 
30 2T, which will specify the length of said parsed path name structure in bytes; 

(c) determining a number P, which represents a total number of Unicode characters which comprise said prefix 
element; 

(d) assigning to the second Unicode character of said unparsed Unicode string a numerical value equivalent 
to 2P. which specifies the length of said prefix element in bytes. 

3S 

6. The method of Claim 5, which further comprises the step of determining the length of ail subelements of which 
said prefix element is comprised and replacing a backslash character which begins each subelement within said 
prefix element with a numerical value specifying the length in bytes of that element. 

40 7. The method of Claim 3, 

wherein, for ASCII path names which do not follow said UNC, each character of the ASCII path name is 
converted to the corresponding Unicode character and written to the buffer to fomi said unparsed Unicode 
string (22A); and 

45 wherein, for ASCII path names which follow said UNC, each character of a subset of said ASCII pathname, 

said subset comprising only two characters preceding the prefix element, the prefix element, and the file name 
element, is converted to the corresponding Unicode character and written to the buffer to fonm said unparsed 
Unicode string (32A). 

so 8. The method of Claim 7, wherein conversion of the unparsed Unicode string (22A, 32A) to a parsed path name 
structure (22B, 328) comprises the steps of: 

(a) determining a number T, which represents a total number of Unicode characters in said string beginning 
with a first character of said string and ending with a null Unicode character which represents a last character 

ss of the Unicode string; 

(b) assigning to said first Unicode character of said unparsed Unicode string a numerical value equivalent to 

2T, which will specify the length of said parsed path name structure in bytes; 

(c) determining a number P, which represents a total number of Unicode characters which comprise said prefix 
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element; 

(d) assigning to the second Unicode character of the unparsed Unicode string a numerical value equivalent to 
2R which specifies the length of said prefix element in bytes. 

5 9. The method of Claim 8, wherein the total Unicode string length T is determined by the steps of: 

(a) pointing to said first Unicode character with a first pointer; 

(b) scanning said unparsed Unicode string by advancing a second pointer in a direction from said first Unicode 
character towards said null character, counting a total number, T+1, of Unicode characters, including the null 

10 character; 

(c) moving said second pointer towards the first pointer by one Unicode character, so that said second pointer 
points to said last Unicode character, subtracting "1 to reflect this one character move, from T+1 , and doubling 
the result to yield a value 2T indicative of the number of bytes required to represent T Unicode characters. 

IS 10. The method of Claim 8, wherein prefix element length 2P, in bytes is determined by the steps of: 

(a) scanning with a third pointer beginning at the Unicode character pointed to by said second pointer and in 
a direction towards said first pointer, stopping said third pointer at a Unicode character corresponding to a first 
backslash character encountered, and counting a number of characters, R including said first backslash char- 

20 acter: and 

(b) calculating the quantity, 2P, which represents the prefix element length in bytes, by subtracting F from T 
and doubling the result. 

11. A computer program product for automatically converting an ASCII path name to a parsed path name structure 
2S (22B, 32B), said ASCII path name having a file name element and a prefix element, said prefix element having at 

least one subelement. the computer program product comprising software code modules directly loadable into the 
internal memory of a digital computer for performing in the appropriate sequence all the steps of the method of 
any one of the preceding claims, when said product is used to control the operation of a computer. 

30 

Patentanspruche 

1. Verfahren zum automatischen Umwandein eines ASCII-Pfadnamens in eine (durch einen Parser) zertegte Rad- 
namenstruktur (22B, 32B), wobel der ASCII-Radname ein Dateinamenelement und ein Praflxelement hat, wobei 
35 das Praflxelement wenigstens ein Unterelement hat, wobei das Verfah ren die folgenden computerimplementierten 

Schhtte aufweist: 

(a) Definieren einer zerlegten Pfadnamenstruktur; 

(b) Zuteilen von Puffern fur Stapelvariable; 

40 (c) Definieren eines Satzes von Abtast- und Zahlfunktlonen und eines Satzes von Arithmetik- und Zeichen- 

Ersetz-Funktionen und Erzeugen einer Vielzahl von Zeigem zur Verwendung mit den Abtast- und Zahlfunk- 
tionen und den Arithmetik- und Zeichen-Ersetz-Funktlonen; 

(d) Bestimmen. ob eine einheitliche Namensgebungskonventlon fur den ASCII-Pfadnamen venvendet wird 
Oder nicht; 

45 (e) Umwandein jedes Zeichens des ASCII-Pfadnamens oder einer Untergruppe davon in ein entsprechendes 

Einheitscodezeichen und sequentielles Schreiben jedes Einheitscodezeichens zu einem Puffer, um eine nicht 
zerlegte Einheitscodekette (22A, 32A) zu bilden; 

(f) Venwenden der Abtast- und Zahlfunktlonen in Kombination mit den Arithmetik- und Zeichen-Ersetz-Funk- 
tlonen, um ein erstes Paar von Pufferstellen in numerische Werte umzuwandein, die jeweils eine gesamte 
so Einheitscodekettenlange und die Prafixelementlange anzeigen. und um jedes Einheitscodezeichen entspre- 

chend einem Invers-Schragstrich-Zelchen innerhaib der Einheitscodekette durch einen spezifischen numeri- 
schen Wert zu ersetzen, der eine Lange in Bytes anzeigt, die zum Radnamenelement gehort, das mit dem 
ersetzten Invers-Schragstrich-Zeichen begann. 

ss 2. Verfahren nach Anspruch 1, wobei der Schritt zum Definieren einer zerlegten Pfadnamenstruktur ein Definieren 
einer Kette von Einheitscodezeichen aufweist, wobei die Kette ein erstes Einheitscodezeichen hat, das einem 
ersten numerischen Wert zugeordnet ist, der eine Lange der Kette in Bytes spezifiziert, wobei die Kette weiterhin 
ein erstes Feld von Einheitscodezeichen aufweist, die das Praflxelement darstellen, wobei dem ersten Feld ein 
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zweites Fold von EinheitsccxJezeichen folgt. die das Dateinamenelement darstellen, wobei dem ersten Einheits- 
ccxlezeichen ein zweites EInlieitsccxjezeichen folgt, das einem zweiten numerischen Wert zugeordnet ist, der eine 
Lange des Prafixelements In Bytes plus vier Bytes spezlfiziert, die das erste und das zweite Einheitscodezeichen 
kontieren, wobei dem zweiten Einheitscodezeichen ein drittes Einheitscodezeichen folgt, das einem dritten nume- 
rischen Wert zugeordnet ist, der eine Lange eines ersten Unterelements des Prafixelements in Bytes spezlfiziert, 
wobei jedem weiteren Unterelement des Prafixelements und des Dateinamenelements jeweils ein entsprechendes 
Einheitscodezeichen vorangeht, das einem numerischen Wert zugeordnet ist, der seine Lange in Bytes spezlfiziert. 

Verfahren nach Anspruch 1, wobei der Schritt zum Bestimmen, ob der ASCII-Radname einer einheitlichen Na- 
mensgebungskonvention (UNO) folgt oder nicht, ein identifizieren von folgendem aufweist: 

eines ASCII-Pfadnamens, der der UNC nicht folgt, beginnend mit einem Treiberspezifizlererzeichen, dem 
jeweils ein Doppelpunkt-Zeichen, ein Prafix beginnend mit einem einzelnen Invers-Schragstrich-Zeichen und 
ein Datelname beginnend mit einem weiteren einzelnen Invers-Schragstrich-Zelchen folgt; 
eines ASCII-Pfadnamens, der der UNC folgt, beginnend mit einem Paar benachbarter Invers-Schragstrich- 
Zeichen, dem jeweils ein Host-Name, ein gemeinsam genutzter Name, der mit einem einzelnen Invers-Schrag- 
strich-Zelchen beginnt, ein Prafix, das mit einem weiteren einzelnen Invers-Schragstrich-Zeichen beginnt, und 
ein Datelname, der mit einem weiteren einzelnen Invers-Schragstrich-Zeichen beginnt, folgt. 

Verfahren nach Anspruch 3, 

wobei fOr ASCIl-Radnamen, die der UNC nicht folgen, jedes Zeichen des ASCII-Radnamens in ein entspre- 
chendes Einheitscodezeichen umgewandelt und zum Puffer geschrieben wird, urn die nk;ht zerlegte Einhelts- 
codekette (22A) zu bilden; und 

wobei fur ASCII-Pfadnamen, die der UNC folgen, zwel besondere Einheitscodezeichen an den Anfang des 
Puffers geschrieben werden, und jedes Zeichen einer Untergruppe des ASCII-Pfadnamens, wobei die Unter- 
gruppe das Unterelement und das Dateinamenelement aufweist. in das entsprechende Einheitscodezeichen 
umgewandelt und direkt benachbart zu den zwei besonderen Zeichen angeordnet wird, und wobei die zwei 
besonderen Zeichen und die Zeichen, die dem Unterelement und dem Dateinamenelement entsprechen, die 
nicht zerlegte EInheltscodekette (32A) aufweisen. 

Verfahren nach Anspruch 4, wobei eine Umwandlung der nicht zerlegten EInheltscodekette (22A, 32A) in eine 
zerlegte Radnamenstruktur (22B. 32B) die folgenden Schritte aufweist: 

(a) Bestimmen einer Zahl T, die eine Gesamtanzahl von Einheitscodezeichen in der Kette beginnend mit einem 
ersten Zeichen der Kette und endend mit einem Einheitscodezeichen von Null, das ein letztes Zeichen der 
EInheltscodekette darsteilt, darstellt; 

(b) Zuordnen eines numerischen Werts gleich 21 zum ersten Einheitscodezeichen der nicht zerlegten EIn- 
heltscodekette, der die Lange der zerlegten Radnamenstruktur in Bytes spezifizieren wird; 

(c) Bestimmen einer Zahl P, die eine Gesamtanzahl von Einheitscodezeichen darstellt. die das Praflxelement 

aufweisen; 

(d) Zuordnen eines numerischen Werts gleich 2P zum zweiten Einheitscodezeichen der nicht zerlegten EIn- 
heltscodekette, der die Lange des Prafixelements in Bytes spezlfiziert. 

Verfahren nach Anspruch 5, das weiterhin den Schritt zum Bestimmen der Lange aller Unterelemente aufweist. 
aus welchen das Praflxelement aufgebaut ist, und Ersetzen eines Invers-Schragstrlch-Zeichens, das jedes Un- 
terelement innerhalb des Prafixelements beginnt, durch einen numerischen Wert, der die Lange jenes Elements 
in Bytes spezlfiziert. 

Verfahren nach Anspruch 3, 

wobei fur ASCIl-Radnamen, die der UNC nicht folgen, jedes Zeichen des ASCII-Radnamens in das entspre- 
chende Einheitscodezeichen umgewandelt und zum Puffer geschrieben wird, um die nicht zerlegte EInhelts- 
codekette (22A) zu bilden; und 

wobei fur ASCIl-Radnamen, die der UNC folgen. jedes Zeichen einer Untergruppe des ASCII-Radnamens, 
wobei die Untergruppe nur zwei Zetehen aufweist, die dem Praflxelement, dem Praflxelement und dem Da- 
teinamenelement vorangehen. In das entsprechende Einheitscodezeichen umgewandelt und zum Puffer ge- 
schrieben wird, um die nicht zerlegte Einheitscodekette (32A) zu bilden. 
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8. Verfahren nach Anspruch 7, wobei eine Umwandlung der nicht zerlegten Einheitscodekette (22A, 32A) in eine 
zerlegte Pfadnamenstruktur (22B, 32B) die folgenden Schritte aufweist: 

(a) Bestimmen einer Zahl T, die eine Gesamtanzahl von Einheitscodezeichen In der Kette beglnnend mit einem 
s ersten Zeichen der Kette und endend mit einem Einlieitscodezelclien von Null, das ein letztes Zeichen der 

Einheitscodekette darstellt, darstellt; 

(b) Zuordnen eines numerlschen Werts gleich 2T zum ersten Einheitscodezeichen der nicht zerlegten Ein- 
heitscodekette, der die Lange der zerlegten Radnamenstruktur in Bytes spezifizieren wird; 

(c) Bestimmen einer Zahl R die eine Gesamtanzahl von Einheitscodezeichen darstellt, die das Prafixelement 
10 aufweisen: 

(d) Zuordnen eines numerischen Werts gleich 2P zum zweiten Einheitscodezeichen der nicht zerlegten Ein- 
heitscodekette, der die Lange des Prafixelements in Bytes spezifiziert. 

9. Verfahren nach Anspruch 8, wobei die gesamte Einheitscodekettenlange T durch die folgenden Schritte bestimmt 
IS wird: 

(a) Zeigen zum ersten Einheitscodezeichen mit einem ersten Zeiger; 

(b) Abtasten der nicht zerlegten Einheitscodekette durch VorrOcken eines zweiten Zeigers in einer Richtung 
vom ersten Einheitscodezeichen zum Zeichen von Null, Zahlen einer Gesamtanzahl T+1 von Einheitscode- 

20 zeichen einschiieQItch des Zeichens von Null; 

(c) Bewegen des zweiten Zeigers In Richtung zum ersten Zeiger urn ein Einheitscodezeichen, so da3 der 
zweite Zeiger zum letzten Einheitscodezeichen zeigt, Subtrahieren von "1 ■ von T+1 , um diese Bewegung um 
ein Zeichen zu berucksichtigen, und Verdoppein des Ergebnisses, damit sich ein Wert von 2T ergibt, der die 
Anzahl von Bytes anzeigt, die zum Darstellen von T Einheitscodezeichen erforderlich sind. 

2S 

10. Verfahren nach Anspruch 8, wobei eine Prafixelementen lange 2P in Bytes durch die folgenden Schritte bestimmt 
wird: 

(a) Abtasten mit einem dritten Zeiger beginnend bei dem Einheitscodezeichen, auf das durch den zweiten 
30 Zeiger gezeigt wird, und in einer Richtung zum ersten Zeiger, Anhalten des dritten Zeigers bei einem Einheits- 
codezeichen entsprechend einem ersten angetroffenen Invers-Schragsthch-Zeichen und Zahlen einer Anzahl 
von Zeichen F eInschlieBlich des ersten Invers-Schragstrich-Zelchens; und 

(b) Berechnen der Quantitat 2P, die die Prafixetementenlange In Bytes darstellt, durch Subtrahieren von F von 
T und Verdoppein des Ergebnisses. 

35 

11. Computerprogrammprodukt zum automatischen Umwandein eines ASCII-Pfadnamens In eine (durch einen Par- 
ser) zerlegte Pfadnamenstruktur (22B, 32B). wobei der ASCII-Pfadname ein Dateinamenelement und ein Prafix- 
element hat, wobei das Prafixelement wenigstens ein Unterelement hat, das direkt in den internen Speicher eines 
digitalen Computers ladbar ist, der Software-Codeteile zum Durchf uhren der Schritte eines belleblgen der voran- 

40 gehenden Anspruche aufweist, wenn das Produkt auf einem Computer lauft. 



Revendlcatlona 

45 1 . Proc6d6 pour convertir automatiquement un nom de chemin exprim6 en ASCI I en une structure de nom de chemin 
analyses (22B, 32B), ledit nom de chemin exprim^ en ASCII ayant un dl^ment de nom de fichier et un ^l^ment 
de prdfixe, ledit ^Idment de pr^fixe ayant au moins un sous-6l6ment, ledit precede comportant les dtapes impld- 
mentdes par ordinateur consistant k : 

so (a) d§finir une structure de nom de chemin analysde, 

(b) allouer des tampons k des variables de pile, 

(c) d^finlr un ensemble de fonctions de balayage et de comptage et un ensemble de fonctions arithm6tiques 
et de remplacement de caract^res et cr6er une plurality de pointeurs destines ^ dtre utilises avec lesdites 
fonctions de balayage et de comptage et lesdites fonctions arithm6tlques et de remplacement de caract^res. 

ss (d) determiner si une Convention d'Appellatlon Uniforme est utilis^e ou non pour le nom de chemin exprimd 

en ASCII, 

(e) convertir chaque caractdre du nom de chemin exprim6 en ASCII ou d'un sous-ensemble de celui-ci en un 
caractdre Unicode correspondant, et dcrire sequentiellement chaque caract^re Unicode dans un tampon pour 
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former une chaTne de caractdres Unicode non-analys6e (22A, 32A), 

(f) utiliser les foncticns de balayage et de comptage, en combinaison avec les fonctions arithmdtiques at de 
remplacement de caract6res pour convertir une premiere paire d'emplacements tampon en valeurs num6ri- 
ques qui sont representatives de la longueurtotale de cliaTne de caract^res Unicode et de la longueur d'^ldment 
de prefixe, respectlvement, et pour remplacer chaque caract^re Unicode correspondent k un caract6re "barre 
oblique inverse" dans ladite chaTne de caractdres Unicode par une valeur numdrtque sp^ifique, representative 
d*une longueur, en octets, associde k reidment de nom de chemin qui commence par le caract^re 'barre 
oblique inverse" remplacd. 

Proc6d6 selon la revendication 1 , dans iequel i'6tape consistent ^ d^finir une structure de nom de chemin analyses 
comports la definition d'une chaTne de caracteres Unicode, ladite chaTne ayant un premier caractere Unicode qui 
est affecte k une premiere valeur numerique specifiant une longueur, en octets, de ladite chaTne, ladite chaTne 
comportant de plus une premiere serie de caracteres Unicode qui represente ledit element de prefixe, ladite pre- 
miere serie etant suivie d'une seconde s6rie de caracteres Unicode qui repr6sente reiement de nom de fichier, 
ledit premier caractere Unicode etant suivi d'un deuxieme caractere Unicode qui est affecte ^ une deuxieme valeur 
numerique specifiant une longueur, en octets, dudit element de prefixe complete des quatre octets qui correspon- 
dent auxdits premier et deuxieme caracteres Unicode, ledit deuxieme caractere Unicode etant suivi d'un troisieme 
caractere Unicode qui est affecte k une troisieme valeur numerique specifiant une longueur, en octets, d'un premier 
sous-eiement dudit element de prefixe, tout autre sous-eiement dudit element de prefixe et dudit element de nom 
de fichier etant chacun precede d'un caiactere Unicode correspondant qui est affecte k une valeur numerique 
specifiant sa longueur en octets. 

Procede selon la revendication 1 , dans Iequel retape consistent k determiner si le nom de chemin exprime en 
ASCII suit ou non une Convention d' Appellation Uniforme (UNC) comporte I'etape consistent k identifier: 

un nom de chemin exprime en ASCII qui ne suit pas ladite Convention UNC commengant par un caractere 
specifiant le repertoire racine suivi, respectlvement, du caractere 'deux points", d'un prefixe commengant par 
un caractere "barre oblique inverse" unique, et d'un nom de fichier commengant par un autre caractere "barre 
oblique inverse" unique, 

un nom de chemin exprime en ASCII qui suit ladite Convention UNC commengant par une paire de caracteres 
"barre oblique inverse" adjecents suivis, respectlvement, d'un nom d'hdte, d'un nom partage qui commence 
par un carectere "barre oblique Inverse" unique, d'un prefixe qui commence par un autre carectere "barre 
oblique inverse" unique, et d'un nom de fichier qui commence par encore un autre caractere "barre oblique 
inverse" unique. 

Procede selon la revendication 3, 

dans Iequel, pour des noms de chemin exprimes en ASCII qui ne suivent pas ladite Convention UNC, chaque 
caractere du nom de chemin exprime en ASCII est convert! en un carectere Unicode correspondant et ecrit 
dans le tampon pour former la chaTne de caracteres Unicode non -analyses (22 A), et 
dans Iequel, pour des noms de chemin exprimes en ASCII qui suivent ladite Convention UNC, deux carecteres 
Unicode suppiementaires sont ecrits tout au debut du tampon, et chaque caractere d'un sous-ensemble du 
nom de chemin exprime en ASCII, ledit sous-ensemble comportant le sous-eiement et reiement de nom de 
fichier, est converti en caractere Unicode correspondant et place immediatement adjecent auxdits deux ca- 
racteres suppiementaires, et lesdits deux caracteres suppiementaires et les caracteres correspondant audit 
sous-eiement et audit element de nom de fichier comportant le cheTne de caracteres Unicode non-anelysee 
(32A). 

Procede selon la revendication 4. dans Iequel la conversion de la chaTne de caracteres Unicode non-analysee 
(22A, 32A) en une structure de nom de chemin analysee (22B, 32 B) comporte les etapes consistent k : 

(a) detemniner un nombre T, qui represente un nombre total de caracteres Unicode dans ladite chaTne en 
commengant par un premier carectere de ledite cheTne et en terminent per un cerectere Unicode nul qui re- 
presente un dernier caractere de la chaTne de caracteres Unicode, 

(b) affecter ledit premier carectere Unicode de ladite chaTne de caracteres Unicode non-analysee k une valeur 
numerique equivalente k 21, qui ve specifier le longueur de ledite structure de nom de chemin analysee en 
octets, 

(c) determiner un nombre P, qui represente le nombre total de caracteres Unicode qui constituent ledit element 



13 



EP 0 800 142 B1 



de prdfixe, 

(d) affecter (edit deuxi^me caractdre Unicode de ladite chaine de caractdres Unicode non-analys6e h une 
valeur numdrique 6quivalente ^ 2P, qui spdcifie la longueur dudit dl^ment de pr^ftxe en octets. 

s 6. Procdd^ selon la revendication 5, qui comporte de plus I'^tape consislant k determiner la longueur de tous les 
sous-^l^ments qui constituent ledit 6l6ment de pr^fixe et k remplacer un caract&re "barre oblique Inverse" qui 
connmence chaque sous-^ldment dans ledit 6\6mer\X de prdfixe par une valeur numdrlque spdcifiant la longueur 
en octets de cet 6ldment. 

10 7. Procddd selon la revendication 3, 

dans lequel, pour des noms de chemin exprimds en ASCII qui ne suivent pas ladite Convention UNC, chaque 
caract^re du nom de chemin exprimd en ASCII est convert! en caract^re Unicode correspondent et est 6cr\X 
dans le tampon pour former ladite chaTne de caract^res Unicode non-analys^e (22A), et 
IS dans lequel, pour des noms de chemin exprim^s en ASCII qui suivent ladite Convention UNC, chaque carac- 

tdre d'un sous-ensemble dudit nom de chemin exprtmd en ASCII , ledit sous-ensemble comportant uniquement 
deux caractdres pr6c6dant I'dldment de prdfixe, de r6l6ment de prdfixe et de I'dl^ment de nom de fichier, est 
convert! en caract^re Unicode correspondant et dcrlt dans le tampon pour former ladite chaTne de caractdres 
Unicode non-analys6e (32A). 

20 

8. Proc6d6 selon la revendication 7, dans lequel la conversion de la chaine de caractdres Unicode non-analys6e 
(22A, 32A) en une structure de nom de chemin analys6e (22B, 32B) comporte les Stapes consistant ^ : 

(a) determiner un nombre T. qui repr6sente le nombre total de caract6res Unicode dans ladite chaTne en com- 
25 men^ant par un premier caract^re de ladite chaTne et en terminant par un caract^re Unicode nul qui represente 

un dernier caract^re de la chaTne de caract^res Unicode. 

(b) affecter ledit premier caract^re Unicode de ladite chaTne de caractdres Unicode non-analysde k une valeur 
numdrique dquivalente k 2T, qui va specifier la longueur de ladite structure de nom de chemin analysde en 
octets, 

30 (c) determiner un nombre P, qui represente le nombre total de caractdres Unicode qui constituent ledit dldment 

de prefixe, 

(d) affecter ledit deuxiSme caractere Unicode de la chaTne de caractdres Unicode non-analysde k une valeur 
num6rique equivalente k 2R qui specifie la longueur dudit eidment de prSfixe en octets. 

35 9. Precede selon la revendication 8, dans lequel ta longueur totale de chaTne de caractdres Unicode T est determinee 
par les etapes consistant k : 

(a) pointer sur ledit premier caractere Unicode k I'aide d'un premier pointeur. 

(b) balayer ladite chaTne de caractdres Unicode non-analysde en faisant avancer un deuxiSme pointeur dans 
40 une direction qui va dudit premier caractere Unicode audit caract^re nul, compter un nombre total, T + 1 . de 

caracteres Unicode, caractere nul inclus, 

(c) deplacer ledit deuxieme pointeur vers te premier pointeur de un caract^re Unicode, de sorte que ledit 
deuxieme pointeur pointe sur ledit dernier caractere Unicode, soustraire la valeur "1 pour refieter ce depia- 
cement de un caractere, de T + 1 , et multiplier par deux le resuttat pour produire une valeur 2T representative 

45 du nombre d*octets necessaire pour representer les T caractdres Unicode. 

10. Procede selon la revendication 8, dans lequel la longueur d'eiement de pretixe 2P, en octets, est determinee par 
les etapes consistant k : 

so (a) balayer k I'aide d'un troisieme pointeur en commengant au niveau du caractere Unicode pointe par ledit 

deuxieme pointeur et dans une direction allant vers ledit premier pointeur, stopper ledit troisidme pointeur au 
niveau d'un caractere Unicode correspondant au premier caractere "barre oblique inverse" rencontre, et comp- 
ter le nombre de caracteres, F, ledit premier caractere "barre oblique inverse" inclus, et 
(b) calculer la quantite, 2P, qui represente la longueur d'eiement de prefixe en octets, en soustrayant F de T 

ss et en muttipliant par deux le resultat. 

11. Produit programme informatique pour convertir automatiquement un nom de chemin exprime en ASCII en une 
structure de nom de chemin analyses (22B. 328), ledit nom de chemin exprime en ASCII ayant un element de 
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nom de fichier et un dl^ment de pr^fixe, iedit 6l6ment de prdfixe ayant au moins un sous-^l^ment pouvant dtre 
chargd directement dans la mdmoire interne d'un calculateur num^rique, comportant des parties de code iogiciel 
pour effectuer les 6tapes de Tune quelconque des revendicatlons pr6c6dentes, Iedit produit Stant exdcutd sur un 
ordinateur. 
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